One of the most common network protocols used today is TCP/IP. The TCP/IP suite typically consists of four layers: the application layer, the transport layer, the network layer, and the link layer.
At the application level, once a user has requested that data be sent from a source application to a destination application (or another instance of the same application) the source application packages the data, in accordance with its own routines, such that it can be read by the destination application. Once packaged by the source application, it is sent to the transport layer, which packages the data for transmission between hosts. At this layer, destination address information is added to the data package. More specifically, an IP address identifies the destination host and a port address identifies the application to which the data is being sent. The data package is then sent to the network layer, which provides the information necessary for routing the information across the network to the destination host. Finally, the link layer provides the command and the information necessary for the interface to actually send the packet. Once the data package arrives at the destination host, each layer is peeled away until the destination application can decode the data contained in the package.
In the TCP/IP suite, there are two major transport-level protocols for transporting application data across the Internet: Transmission Control Protocol (TCP), and User Datagram Protocol (UDP). TCP is based on the notion of a “connection” between two hosts, within which they can send data to each other reliably, without the possibilities that: (1) the data will be lost along the way, or (2) the data will be received in a different order than it was sent. TCP is used, for example, for essentially all web browsing, file transfers, and email transmissions.
UDP, on the other hand, is based on the underlying IP model, in which data is sent in individual packets from one host to another. In UDP, any given packet may well: (1) not arrive at its destination, or (2) arrive more than once even though it was sent only once, or (3) arrive before the arrival of other packets that were sent earlier. UDP is used in contexts where it is not essential that all of the data arrive at the destination (perhaps because the application is detecting and recovering from packet loss), or where the transmission-latency costs of TCP (e.g., connection set-up, data retransmissions, etc.) are unacceptable. A common example of a type of transfer in the Internet today that uses UDP is the transmission of streaming audio and video data.
Within UDP, there are two major methods for data packets to be addressed and delivered: unicast and multicast. In both methods, each UDP packet contains source and destination addressing information and a UDP “port” number.
In the unicast method, the sending application uses its host's own IP address and the application's own UDP port number as the source addressing information. For the destination addressing information, the sending application uses the IP address of the remote host with which it intends to communicate and the UDP port number of the specific application on that host intended to receive the data. When the packet is sent, the network makes a “best effort” to deliver the packet to the host and application described in the destination addressing information.
In the multicast method, the source addressing information is set exactly as in the unicast method, but the destination information is different. Here, one of a special set of IP addresses is used to describe not a single host, but rather a whole set of hosts. These multicast addresses function like radio frequencies: any individual host on the network can, without prior notice or central coordination, dynamically register its interest in receiving anything sent to a particular multicast address, in the same way one might tune a radio receiver to a particular frequency. When a UDP packet is sent using a multicast address for the destination addressing information, the network makes a “best effort” to deliver one copy of the packet to every host that has registered interest in that address. Further, the network attempts to accomplish this delivery in an efficient manner, sending only one copy of the packet across any particular network link. For applications where there are multiple receivers of the same transmitted data, it is much more efficient to send a single copy by multicast than to send multiple copies of the same packet to each individual receiver via unicast. While it is sometimes useful for a user to be able to express a preference for unicast transmission even if multicast would work, in most circumstances, it is better if all multicast-capable clients use multicast, leaving unicast use only to non-multicast-capable clients.
In addition, it is important in many applications for the server to be able to determine the source of each data packet it receives. Packets from different clients might be handled differently by the server (and some packets, such as those that did not come from a registered client, may be ignored altogether). Further complicating the situation is the fact that certain network components, architectures, and applications may affect the source address found in packets sent by the client. More specifically, multi-homed computers (i.e. computers that have more than one IP address, usually with each address assigned to a different network interface) may affect which source address the client should use. For example, a host might have one or more Ethernet cards, dialup modems, or a combination of the two. When an application on a multi-homed computer sends a network packet, the IP source address in that packet may be any one of the interfaces available. The choice of source address is determined by several factors, including which interfaces are currently enabled (e.g., an Ethernet card may not have a cable connected to it, or a dialup modem might not currently be engaged in a phone call), and the network's routing topology (e.g., a server might be reachable from one Ethernet connection to a client, but not from any of the others, or the server might simply be closer, in network hops, via one Ethernet connection than another). It is often not feasible for an application to determine a priori which IP source address will be used for any given UDP packet transmission. Most operating systems do not provide any mechanism for applications to acquire this information directly.
A client's choice of source addresses may be further affected when the network utilizes a Network Address Translator (NAT) device. For a variety of reasons, including security and the difficulty of acquiring large blocks of public IP addresses, many organizations use a set of private-use-only IP address ranges internally. As a result, many of the IP addresses used within the network become invalid for use outside the local network. To remedy this, some organizations or local area networks, at the border between their internal networks and the public Internet, deploy a NAT device. The NAT device maps local, or private-use-only IP addresses to available globally-valid addresses. When using a NAT device, the user of a client in a local network can send a communication to a client outside the local network using its local IP address, regardless of whether the IP address is globally valid. The NAT device transparently maps the local address to a globally-valid address and sends the communication to that globally-valid IP address. Any response from the client arrives at the NAT device, at the globally-valid IP address. The NAT device maps the address back to the local IP address for communication back to the original sender. As a result of the mapping performed by the NAT device, it may be very difficult for a client to determine, a priori, which source IP address will be seen by a given server when the client communicates with it.
In peer-to-peer UDP applications, data is transmitted via UDP among a group of clients across a digital network. Each packet of data transmitted by one client is intended to be received by all of the other clients. For example, in a multi-party audio conversation application, the digital audio samples representing each utterance by one user should be transmitted to all other users participating in the same conversation. Since each transmitted packet of data is to be delivered to multiple destinations, such an application is a good match for the capabilities provided by multicast. Unfortunately, multicast delivery is not currently supported everywhere on the Internet. Worse, there is no way for one host to know, a priori, whether multicast delivery is supported between that host and any specific other host on the network.
As a result, most such applications simply ignore the possibility of using multicast delivery and rely exclusively on unicast, thereby forgoing any potential bandwidth savings that might accrue from using multicast where possible.
A more useful alternative allows each multicast-capable client to use multicast while non-multicast-capable clients use unicast. To achieve this, a server acts as a kind of gateway between those clients that can use multicast and those that cannot.
Technically, essentially all clients are capable of using multicast, but the networks between them may not be capable of (or configured to allow) carrying multicast traffic between them. In the theoretical worst case, multicast connectivity could be enabled or disabled independently between every pair of clients. This could only be done, however, in a network (or set of networks) that is configured without regard to the normal criteria used in designing networks, such as the efficient use of bandwidth and consistency among computers within the network. It is therefore sufficient to determine just whether or not each client can communicate via multicast with the server. In a network that is configured reasonably, if two different clients can each use multicast to communicate with the server, then they should be able to use multicast to communicate with each other.
Whenever a multicast-capable client sends a packet, the server receives it (along with all of the other multicast-capable clients) and transmits copies of the packet via unicast to each of the non-multicast-capable clients. Whenever a non-multicast-capable client wishes to send a packet, it sends it via unicast to the server. The server then transmits one copy via multicast to all of the multicast-capable clients simultaneously, and multiple other copies via unicast, one to each of the other non-multicast-capable clients. In this way (ignoring possible packet loss in the network, inherent in all UDP transmissions), any packet sent by any client (whether multicast-capable or not) is ultimately received by every other client. At the same time, overall network usage is decreased relative to the all-unicast approach described earlier.
In this hybrid unicast/multicast approach, the server needs a list of all of the non-multicast-capable clients, so that it can know where to re-transmit the packets it receives. It is helpful as well, if the server also has a list of all of the multicast-capable clients. When that list is empty, the server can avoid retransmitting received unicast packets via multicast, further reducing network usage. A simple mechanism for maintaining these lists is to require each client to register with the server (via some reliable communications medium, such as TCP connections) when joining the application and to unregister from the server when leaving. For each client, the server needs to know whether transmissions to and from that client should be sent via unicast or multicast, and the IP address and (unicast) UDP port of the client. The latter is needed for three purposes: (1) for unicast clients, so that the server knows where to re-transmit packets intended for that client; (2) for all clients, so that the server can tell which client sent any given packet received by the server; and (3) so the server can ignore any received packets that did not come from a registered client.
While it is sometimes useful for a user to be able to express a preference for unicast transmission even if multicast would work, usually it's better if all multicast-capable clients use multicast, leaving unicast use to non-multicast-capable clients. The vast majority of users, however, are not competent to determine whether their clients and/or networks are multicast-capable in the context of any particular application. Similarly, most users are not competent to determine whether their computers are multi-homed, or, if so, which of the multiple available IP addresses will be used in the context of any particular application. Finally, most users are not competent to determine whether network transmissions to and from their computers within the context of any particular application will traverse a NAT unit or, if so, what form the NAT modifications will take. In summary, prior art techniques do not assist a computer user in fully optimizing packet communication over a network.
There is a need to overcome these and other shortcomings of the prior art and to provide an efficient method for seamlessly optimizing communication over a network. The present invention, as illustrated in the following description, is directed to solving one or more of the problems set forth above.